home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / news / readers / nnr / nnr_133.readme next >
Encoding:
Text File  |  1993-09-11  |  9.9 KB  |  279 lines
  1. NNR (S_1.3.3) and (R_1.3.3) update announcement.
  2.  
  3. SPECIAL THANKS:
  4.     Arty Ecock @ City University New York
  5.     Ken Hornstein @ Pennsylvania State University
  6.  
  7.  
  8. * NNR (RXSOCKET)
  9.  
  10. as of NNR S_1.3.2 the principal version of RXSOCKET will be V2.  i
  11. have hooks into NNR to support REXTCPIP which could easily be
  12. modified if there were a need to adapt RXSOCKET V1.  please let me
  13. know if you have a situation where migration to RXSOCKET V2 is
  14. impossible and i'll generate the necessary updates.
  15.  
  16. as of *_1.3.3 NNR will be sensitive to the INN news server.  there
  17. are excerpts from the INN FAQs following the usual announcement stuff.
  18. one note, although INN is much faster for posting it is also less
  19. forgiving.  you will find when following-up an article you will need
  20. to supply more new text than re-posted old text.
  21.  
  22.  
  23. /* FX133S1  * add ability to migrate to a new server and preserve groups */
  24.  
  25. nnr has the ability to talk to multiple news servers and will
  26. maintain a "NNReader" for each.  in many cases a user will check
  27. other servers primarily for groups that do not exist on his/her
  28. primary server as in the instance of the regional groups which do not
  29. have the world wide distribution.  this fix may be overkill for the
  30. above mentioned user since his/her "Personal_Subscription" list will
  31. be propagated.
  32.  
  33. this fix is ideally suited for those sites migrating a user base to a
  34. new news server where it is desirable to preserve the users
  35. "Personal_Subscription" list partially intact.  partially?  the list
  36. of groups and personal HLI's will be rebuilt for the new server and a
  37. new "NNReader" file will be generated.  the new server will be
  38. interrogated to determine the first and last articles known to the
  39. server.  this process will not maintain any history associated with
  40. a group.
  41.  
  42. it is possible to comment this fix in the "NNR$XEDI AUXRXS" file but
  43. it is far easier to remove groups from the "Personal_Subscription"
  44. list than to add them.
  45.  
  46. /* FX133S2  * fix newgroups, for INN compatibility */
  47.  
  48. the INN server command "NEWGROUPS" returns more information than the
  49. same command on the old nntp servers.
  50.  
  51.  
  52. /* FX133S3  * say the server name on screen banners */
  53.  
  54. a cosmetic change was made to all screens so that the news server
  55. name can appear.
  56.  
  57.  
  58. /* FX133S4  * add XOVER */
  59.  
  60. XOVER is a new extension to the NNTP protocol which will allow access
  61. to the Overview database.  the Overview database contains header
  62. information about all the articles in all the groups.  the client
  63. (nnr) can now with a single command get most anything it needs
  64. concerning an article with a single command (XOVER).
  65.  
  66. you will notice on the Preferences Screen that the entry for
  67. selecting the display headers has been replaced with a similar entry.
  68. the new entry has 5 pre-configured Header screen setups:
  69.  
  70.   1  mode="Subject . . From"
  71.   2  mode="Subject Lines . From"
  72.   3  mode="Subject . . From"
  73.   4  mode="Subject Lines Date From"
  74.   5  mode="Subject . . ."
  75.  
  76.  
  77. /* FX133S5  * replace POST with SORT on Headers screen */
  78.  
  79. the "Post" function was remove from the Headers screen and replaced
  80. by the "Sort" function which was formerly only a command line feature.
  81.  
  82.  
  83. /* FX133S6  * get preferred name for posting and mail */
  84.  
  85. during a posting or mailing nnr will detect that a user doesn't an
  86. entry for himself/herself in the "userid() names" file, at this time
  87. a message will be sent to the screen suggesting that they enter the
  88. PREFERences screen to add one.  the preferred name will be maintained
  89. as a nnr name and not a Names file name.
  90.  
  91.  
  92. /* FX133S7  * allow for sorted headers */
  93.  
  94. there is now an entry on the Preferences screen to tell nnr to sort
  95. each Header screen prior to display.  this will align all a subjects
  96. and have the same effect as doing the "Thread" function for subject
  97. thread.
  98.  
  99.  
  100. /* FX133S8  * pack and unpack session variables to and from session file */
  101.  
  102. now that we can set several session values it is important to
  103. preserve them across nnr sessions.  to do this nnr maintains a
  104. "SESSION NNR A" file which can be user modifiable.  this file
  105. overrides select system configured golbalv variables.
  106.  
  107.  
  108. /* FX133S9  * check the news server, see if xover available. */
  109.  
  110. this fix checks the server to see if we can user any of the INN
  111. server features.
  112.  
  113.  
  114. /* FX133SA  * add XHDR stuff to do the XOVER equivalent */
  115.  
  116. in order to add the XOVER stuff i was forced to remove the old way of
  117. handling the same function.  once XOVER was working to my satisfaction
  118. the XHDR section had to be reworked.
  119.  
  120.  
  121. /* FX133SB  * miscellany, tweak previous fixes */
  122.  
  123. this fix removed the "X-Newsreader" header.  the general consensus on
  124. the network revealed that it was not a worthwhile header.
  125.  
  126.  
  127. /*       * add version number                                         */
  128.  
  129. added version number for reporting problems.
  130.  
  131.  
  132. * NNRLIST
  133.  
  134.  
  135. /*       * add version number                                         */
  136.  
  137. added version number for reporting problems.
  138.  
  139. *****************************************************************
  140. many thanks to the University of Stuttgart and the
  141. Instituto Tecnologico de Monterrey for the anonymous ftp
  142. -----------
  143. Anonymous FTP to VMTECQRO.QRO.ITESM.MX or 132.254.90.1
  144. CD NNR
  145.  
  146. 8:00-23:00 CST Mon. to Fri.
  147. 9:00-16:00 CST Sat. & Sun.
  148. -----------
  149. FTP rusmv1.rus.uni-stuttgart.de or 129.69.1.12
  150. cd /soft/kommunikation/news/beginner/software/nnr
  151. -----------
  152.  
  153.    source.vers130 - nnr sequenced source and support files
  154.    updates.vers133  - individual updates
  155.    nnrrxtcp.noas133 - nnr (without rextcpip)
  156.    nnrrxsoc.noas133 - nnr (without rxsocket) (requires fal version 2)
  157.    nnrdocs.vers133 - nnr users guide (script and postscript)
  158.  
  159.  
  160. the above mentioned files are in a punch format and the following
  161. procedure will unpack them.
  162.  
  163.        SPOOL PUN *
  164.        PUNCH Filename Filetype <fm> ( NOH
  165.        ORDER RDR <spid>
  166.        READCARD * * <fm>
  167.  
  168. notice that the pre-packaged files no longer contian any of the
  169. assembler code (RXSOCKET or REXTCPIP).
  170.  
  171. if you need RXSOCKET:
  172.    if on BITNET:
  173.      TELL LISTSERV at CUNYVM get rxsocket package
  174.    if on Internet (mail only):
  175.      send mail to
  176.        "listserv@cunyvm.cuny.edu"
  177.      the body of the message should contain 1 line
  178.        "get rxsocket vmarc ( f=uue"
  179.      (you will need the uuencode and vmarc to unpack the mail file)
  180.  
  181. if you need REXTCPIP:
  182.    if on BITNET:
  183.      TELL LISTSERV at OHSTVMA get rextcpip package
  184.    if on Internet (mail only):
  185.      send mail to
  186.        "listserv@ohstvma.acs.ohio-state.edu"
  187.      the body of the message should contain 1 line
  188.        "get rextcpip package"
  189.  
  190.  
  191. use the command "gnnrx" to generate the rxsocket version and
  192. "gnnrt" for the rextcpip version from source.vers130 and
  193. updates.vers132.
  194.  
  195. In NNR exec:
  196.    set variable ipaddr : ip address
  197.                 mailer : mail machine
  198.           organization : your organization
  199.               thisnode : yournode.yourdomain
  200.  
  201.    make appropriate update for link to production tcpmaint 592
  202.    make appropriate update for printing
  203.  
  204. See "NNR SAMPLEFX" - update, make changes to this file for your site
  205. and file it as "NNR SITEFIX".
  206.  
  207. /pc
  208.  
  209. -------------
  210. Paul Campbell
  211. The MITRE Corporation
  212. Bedford, MA, USA 01730 : (617)271-3984
  213. nnrprod@mbvm.mitre.org
  214.  
  215.  
  216. from INN FAQs:
  217.  
  218. > From: tal@Warren.MENTORG.COM (Tom Limoncelli)
  219. >Subject: INN FAQ Part 1/3: General Information, how to compile, how to operate
  220. > Subject:  What is INN?
  221. >
  222. > InterNetNews is a complete Usenet system.  The cornerstone of the
  223. > package is innd, an NNTP server that multiplexes all I/O.  Think of
  224. > it as an nntpd merged with the B News inews, or as a C News relaynews
  225. > that reads multiple NNTP streams.  Newsreading is handled by a
  226. > separate server, nnrpd, that is spawned for each client.  Both innd
  227. > and nnrpd have some slight variances from the NNTP protocol (although
  228. > in normal use you will never notice); see the manpages.  INN
  229. > separates hosts that feed you news from those that have users reading
  230. > news.  If you need to support a mixed environment you will have to do
  231. > some extra work; the installation manual gives some hints.
  232.  
  233. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  234.  
  235. >From: rob@agate.Berkeley.EDU (Rob Robertson)
  236. >Subject: FAQ:  Overview database / NOV General Information
  237. >
  238. >------------------------------
  239. >
  240. >Subject: What is the Overview/NOV database?
  241. >
  242. >The Overview or News OverView (NOV) database was designed by Geoff
  243. >Collyer.  Its a more generalized database, it it contains *no*
  244. >threading information, just the information needed to thread.  The
  245. >overview database is just a database of files, one for each group,
  246. >containing a reference to each article, with seven or eight of the
  247. >most popular headers.  Thus, the newsreader client can get most of the
  248. >information it needs to thread, but it does the threading the way it
  249. >wants to.  Yes, the downside is that now the threading occurs on the
  250. >client's CPU, but that's not as expensive as it may seem, if done
  251. >properly.
  252. >
  253. >------------------------------
  254. >
  255. >Subject: What is XOVER?
  256. >
  257. >XOVER is an NNTP extension for accessing the Overview database.  It
  258. >is becoming a defacto standard for accessing bulk header/thread
  259. >information via NNTP.
  260. >
  261. >It is used after establishing a current group with the GROUP command,
  262. >and operations on that group.  It's syntax is
  263. >
  264. >    XOVER artnumber1[-artnumber2]
  265. >
  266. >Where artnumber1 is < artnumber2.  If successful, it returns a 224
  267. >reply code, and the overview data [as in the Overview database] for
  268. >the requested articles.  It is terminated by a "." (dot) on a line by
  269. >itself.
  270. >
  271. >NNTP servers implementing the XOVER command should try to ensure that
  272. >the data is as consistant as possible, they should avoid handing out
  273. >XOVER information for articles that don't exist, and should generate
  274. >XOVER information on the fly for articles that do exist, but aren't
  275. >found in the Overview database for some reason.  While the job of
  276. >XOVER is to provide access to the Overview database, validating the
  277. >Overview data is best done in the NNTP server, rather than having the
  278. >NNTP client go through contortions to do it.
  279.